當系統只有兩三個工具時，最直覺的設計通常是先做一個 Router：看到數據問題就送到 Google Sheets，看到文件問題就送到 RAG，看到專案問題就送到 Trello 或 Jira。這種方式簡單、容易理解，也很適合作為第一版。

但當問題開始跨來源，Router 很快就會不夠用。原因是它通常只回答一件事：「這個問題應該送去哪裡？」真正的任務卻可能需要先查 A，再根據 A 的結果決定是否查 B，最後還要整合不同來源，並判斷目前資料到底夠不夠。

這時候就需要另一個角色：Coordinator（協調者）。

Router 的角色比較像總機

Router 的工作主要是分類與分流。例如系統先判斷使用者輸入屬於哪一種類型，再交給對應 Tool。

例如「今年台灣有多少工單？」可以被分類成 data_query，接著直接送到 Google Sheets Tool；另一個問題「公司的差旅政策怎麼規定？」則可以分類為 document_query，再交給 RAG。

這類問題的共同特徵是：一個問題通常對應一個主要 Tool，而且執行路徑很清楚。 因此 Router 很適合處理單一意圖。它的好處是成本低、行為容易預測，也很方便測試。

跨來源問題，Router 很快就會遇到限制

假設使用者問：「找出今年問題最大的市場，說明這個問題的正式定義，並確認是否有相關改善專案。」如果 Router 必須從 data_query、document_query、project_query 三個類別中選一個，它就會陷入困難，因為正確答案其實是：三個都需要，而且還有執行順序。

這個問題可能需要先查 Google Sheets，找出問題最大的市場（例如 Hong Kong）；接著再根據 Hong Kong 或 Top Issue，到 PDF / Confluence 查詢問題定義；最後才到 Trello / Jira 查詢 Project Status。也就是：

使用者問題 → 查數據 → 取得結果
→ 根據結果查文件 → 根據結果查專案 → 整合回答

Router 可以決定「送去哪裡」，但它通常不負責管理這整段任務。

Coordinator 比較像專案經理

如果把 Router 想成總機，Coordinator 就比較像一位專案經理。它不只是把任務分派出去，而是需要持續掌握：

• 使用者真正想完成什麼
• 已經取得哪些資料
• 哪些資訊仍然缺少
• 下一步應該使用哪一個 Tool
• 是否可以沿用之前的結果
• 某個 Tool 失敗後要不要改變策略
• 目前是否已經足夠回答

可以把 Coordinator 的工作簡化成：

這其實和前一天介紹的 ReAct 很接近。不同的是，今天我們開始把這個能力放回整體架構中，理解為什麼 Data Machi 需要一個 Coordinator 來管理多個 Tool。

Coordinator 必須知道「目前已經知道什麼」

Coordinator 和 Router 最大的差異之一，就是它需要維持任務狀態。假設使用者先問「今年哪個市場的需求問題最多？」，系統查到 Hong Kong，Request Count = 1,640。接著使用者只說「那相關專案呢？」。

這句話本身其實資訊非常少。如果當成一個全新的 Query，系統根本不知道「那」到底指什麼。但 Coordinator 如果保留前一輪資訊，就可以理解：

Previous Result:
Top Market = Hong Kong

Current User Message:
「那相關專案呢？」

Resolved Intent:
查詢 Hong Kong 相關改善專案

接著再呼叫 get_project_status(market="Hong Kong")。這就是 Context 在 Coordinator 中的重要性。

Context 不等於把所有聊天紀錄全部丟給模型

提到上下文，很容易想到「那就把整段 Conversation History 全部塞進 Prompt」。但真正需要保存的，不一定只是完整對話文字。對 Coordinator 更有價值的是已經被確認過、後續仍然需要使用的任務資訊。例如：

Current Task: 分析今年需求問題
Selected Period: 2026 YTD
Top Market: Hong Kong
Top Category: Delivery Issue
Used Tools: Google Sheets Tool, Document Tool
Pending: Project Status

這種結構化資訊，比單純把前面二十輪對話全部交給模型更容易管理。後面介紹 LangGraph State 時，我們會看到這些資訊如何進一步變成 Workflow 的 State。

使用者每講一句話，都需要重新查資料嗎？

Coordinator 還有一個很重要、但不容易被注意到的責任：判斷現在到底需不需要重新工作。

假設前一輪已經查到 Hong Kong Request Count = 1,640，Source 是 Google Sheets，Retrieved At 是 16:00。使用者下一句說「幫我整理成表格。」，這時候沒有必要重新呼叫 Google Sheets。Coordinator 應該知道目前只是呈現方式改變，只要沿用既有結果（Reuse the Existing Result），再把它整理成表格（Format as Table）就好。

如果每次都重新查資料，不只增加 API Call 和等待時間，還可能因為資料剛好在兩次查詢之間更新，造成同一段對話前後數字不一致。因此 Coordinator 除了知道「什麼時候做事」，也要知道什麼時候不要做事。

可以把使用者訊息分成幾種不同類型

為了判斷需不需要重新查詢，可以先把常見訊息簡單分成幾類。

這個分類其實不一定需要做得非常複雜，但它提醒我們：不同訊息代表的「工作量」完全不同。Data Machi 的 Coordinator 在每一輪開始時，會先用較快的模型做一次這樣的判斷（程式裡的 classify_turn_context），輸出包含 domain_hint、能不能直接用既有上下文回答，以及是否要強制重新查詢。

例如「整理成表格」真正需要的只是 Reformat，而不是「Re-query Google Sheets → Re-run RAG → Re-check Project → Generate Table」。後者只是浪費資源。

什麼時候一定要重新查？

反過來，有些訊息則明確代表使用者需要最新資料。例如「你確定嗎？再查一次。」或「我剛剛更新 Sheet 了，重新確認。」，Coordinator 應該把這類訊息理解為 force_refresh = true，也就是即使 Cache 還沒有過期，也應該重新查詢 Source of Truth。

另一種情況是條件改變，例如「那去年呢？」。如果前面的結果是 2026，這次必須重新使用 period = 2025 查詢，而不能只把「2026」文字替換成「2025」。因此可以簡化成：

只是改格式？
→ Reuse

只是翻譯？
→ Reuse

問題條件改變？
→ Re-query

要求重新確認？
→ Re-query

完全新問題？
→ New Task

Router 與 Coordinator 怎麼一起工作？

Router 和 Coordinator 並不一定只能二選一。一個實際系統中，很可能是 Coordinator 內部先使用 Router，快速判斷目前問題大概屬於哪一類，再決定後續行動。例如：

使用者問題
    ↓
Coordinator
    ↓
Router / Domain Classification
    ↓
初步判斷：
Project Query
    ↓
Coordinator
    ↓
目前資訊足夠嗎？
    ↓
需要先查文件定義嗎？
    ↓
選擇下一個 Tool

Router 可以提供一個初步的 Domain Hint，但 Coordinator 才負責最後的執行策略。這個差異很重要。假設 Router 判斷這是 project_query，但 Project Tool 回傳 No project found，Coordinator 不應該因為第一步分類成 Project Query，就直接宣告「沒有專案」。它可以根據 Observation 改變方向，例如先去 Document Tool 查正式名稱。因此：

Router 的判斷是建議，不一定是最終命令。

Domain Hint 是起點，不是絕對命令

假設使用者說「CDP 現在進度怎麼樣？」，初步 Router 很合理地會判斷 Domain = Project，接著查 get_project_status("CDP")，但結果是 No Result。這時候 Coordinator 可以重新評估可能的原因：

1. 專案不存在
2. CDP 是縮寫
3. Project Tool 使用不同名稱
4. 目前沒有權限

如果 Tool Result 表示只是查不到名稱，Coordinator 可以改用 search_documents("CDP")，找到：

CDP = Customer Data Platform
Project Name = Customer Data Platform Dashboard Revamp

再重新查 Project Tool。

如果一開始的 Router 是硬規則，規定 project_query 只能用 Project Tool，第一次分類錯誤或資訊不足，就可能一路錯到底。比較好的架構是：Router 提供初步方向，Observation 提供新的證據，Coordinator 則可以根據證據修正方向。這也延續了 Day 17 ReAct 的概念。

Coordinator 需要保留哪些資訊？

走到這裡，可以先整理 Coordinator 最基本的 State。至少可能包括：

例如：

Current Question:
「那相關專案呢？」

Context:
Previous Top Market = Hong Kong

Domain Hint:
Project

Tool History:
query_google_sheets

Existing Result:
Hong Kong = 1,640 requests

Missing:
Improvement Project Status

Task Status:
IN_PROGRESS

有了這些資訊，Coordinator 才能知道下一步應該執行 Project Tool，而不是從頭重新查一次所有資料。

Coordinator 還要知道任務是否真的完成

Router 的任務通常在分流之後就完成了：收到問題、完成分類、送到 Tool，Router 的工作就結束。Coordinator 則需要持續追蹤到「使用者目標是否已經被滿足？」。

假設使用者問「找出需求最多的市場，並確認是否有相關改善計畫。」，目前只得到 Top Market = Hong Kong。即使 Sheets Tool 已經成功，整個任務仍然是 IN_PROGRESS。直到又取得 Improvement Project = Delivery Experience Improvement、Status = In Progress，才可以變成 COMPLETED。

這也說明 Coordinator 關注的不是某一次 Tool Call 是否成功，而是：

使用者原本的任務是不是已經完成。

Router 與 Coordinator 怎麼選？

可以用下面這張表快速比較：

如果每個問題都只需要一個明確 Tool，Router 通常就已經足夠。沒有必要因為 Agent 很熱門，就硬加上一層 Coordinator。但當系統開始同時需要多步驟、跨來源、前後文、結果重用、Observation 與重新決策時，Coordinator 的價值就會開始變得很明顯。

Data Machi 為什麼不是一開始就做萬能 Coordinator？

回頭看整個系列的順序，其實是刻意的。我們先建立 PDF RAG，再建立 Google Sheets Tool，接著才處理 Cross-source Workflow，然後才加入 Agent、ReAct 和 Coordinator。這個順序的原因，是希望每一項底層能力都能先被單獨驗證。

如果從 Day 06 就建立一個「萬能 Agent」，讓它自己處理 PDF、Sheets、Project、Memory 和 Verification，最後回答錯誤時，我們很難知道是哪一層有問題。現在則可以清楚拆分：

資料讀錯？
→ Tool

工具選錯？
→ Coordinator

前一步結果沒有帶到下一步？
→ State

沒必要卻重新查？
→ Reuse Policy

資料不足卻回答？
→ Completion / Verification

這也是為什麼企業 Agent 架構真正重要的不是「自動化程度有多高」，而是每一層責任是否清楚。

實務踩坑｜知道什麼時候「不做事」

Coordinator 最容易被忽略的一項能力，就是知道什麼時候可以直接沿用既有結果。

假設 16:00 使用者問「今年台灣工單多少？」，結果是 328。16:01 使用者說「幫我整理成一句給主管看的話。」這時候如果 Coordinator 再去查一次 Sheets，可能新資料剛好進來，New Result 變成 329。於是同一段對話會變成第一輪 328、第二輪 329，使用者反而可能困惑：「為什麼我只是叫你改格式，數字就變了？」

因此資料重用不只是節省成本，也和對話一致性有關。比較合理的設計是回答：

「截至今天下午 4 點的資料，今年台灣共有 328 筆工單。」

如果使用者真的希望重新確認，則明確說「再查一次最新數字。」，這時才重新存取 Source of Truth。

今天的重點：
Router 解決的是「這個問題應該送去哪裡」，Coordinator 解決的是「這個任務接下來應該怎麼做，直到使用者的目標真正完成」。好的 Coordinator 不只會選 Tool，還要知道目前已經知道什麼、什麼時候需要重新查，以及什麼時候其實什麼都不用做。

下一篇，我們會真正把 Google Sheets Tool 與 PDF RAG 掛到同一個 Coordinator 底下，讓使用者只需要用自然語言提出問題，不再需要自己決定應該使用哪一個工具。

我們下集見囉！